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In an operating system, a function to address resources in executable files is modified to redirect "I'f f;^";^,^^^^ 
resources res^onsively to a user-setting defining a selected language. TTie 

modules through a dynamic addressing scheme that allows the alternate language file suue to ^^^/^Pfj^^^ J'^^ 

routing facilitv^ The invention provides resource-handling components, the capability for handling multiple-language "^"^^ J^'^^^^ 

^uTrfnra7specm^ directions from the processes requesting the resources. TOs allows the ^^^J^^'T^'^^ 

Sport while uihig existing resource and executable binaiy files without modification. A us«^ is enabled to select a language for the user 

interface and the resource loader will automatically redirect calls for resources to the appropnaie resources. 
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MULTILINGUAL USER INTERFACE FOR AN OPERATING SYSTEM 



Tsrhniral Field 

The present invention generally relates to operating systems, and more 
particularly to operating systems that provide an efficient mechanism for 
5 switching the user-interface language. 



RanVgroHTiH nf the Invention 

A resource is binary data or non binary data, e.g., a text file. In Windows NT® 
and all other 0/S of the Windows® family, resources are binary data. 
Resource data can reside in the executable file of an application, so the 

0 executiible file is a binary file with code and resource data in it Processes 

defined by the code can use the resources in their own binary executable files 
or other racecutable files. Resources used by such processes may also reside in 
resouice-only files, for example, resource-only dynamic link libraries (DLLs). 
A resource may be either standard or user-defined. The data in a standard 

.5 resource describes an icon, cursor, menu, dialog box, bitmap, enhanced 

metafile, font, accelerator table, message-table entry, string-table entry, or 
version. A user-defined resource contains any data required by a spedfic 
application. The resources required by operating system processes may be 
handled in various different ways. Many of these resources include words, 

JO symbols, formatting data, etc. that are language-specific. Usually, a particular 

language is determined by the operating system installation package chosen by 
. the user. If the language of the software is Englidi, only the English-language- 
specific resources will be installed with the operating system. This is 
convenient because of the large quantity of language-specific resources that 

2 5 would have to be copioi on the hard-disk to cover all languages. 

Providing a single language for the operating system to support is also 
convenient because it allows resources to be efficiently loaded and unloaded 
into and from memory as the need arises. Far too many resources exist for all 
to reside in memory at all times. To manage the loading and unloadmg of 

3 0 resources so tiiat resources do not lumecessarily occupy memory when not 
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required, the code that generates the processes requiring the resources and the 
resources peculiar to the process may be incorporated in the same binary files. 
When a process is invoked, a binary file containing the code for the process, 
and the attendant resources, may be loaded into memory or otherwise made 
accessible to the process. When the process is terminated, the resource and 
code sections of such a file are unloaded firom memory or otherwise made 
inaccessible. These binary files can be executable programs, dynamic link 
libraries (DLLs), device drivers, etc. If they were bloated with all the 
alternative language resources, an excessive amount of memory would be 
required* 

An example of how one operating system handles such resources is as follows. 
First, a resource finder, an operating system fimction, is eny^loyed to create a 
handle to the specified resource's info block. A process requiring a resource 
sends the finder a resource module handle and the resource name, type, and 
optionally, a language ID. The latter specifies a language specific resource in 
the resources defined by the resource module handle* The finder returns a 
handle to the specified resource's info block and the process can call a resource 
loader to place ttie resource in memory. The process gives the resource handle 
and the resource module handle to the resource loader, which places tiie 
resource in memory and returns a handle to the memory block containing the 
resource. The resource is then available to the process. The operatmg system 
may then use other devices to fi:ee the memory after the process loading it into 
memory no longer needs it, is terminated, or if other conditions require it. 
The above is only one typeof resource access facility in an example operating 
system. Other mechanisms may make resources avalable in other ways, such 
as by placing text messages in an output buffer, inunediately loading and 
returning a handle to resource data in a single fimctioti call, etc. The common 
feature of these mechanisms is that they find a resource either in memory or in 
a disk file or other storage system and make the resource available to the 
process that requires it. This may involve loading a file &om disk into memory 
or just providing access to the resource by providing a handle or some other 
device. The file (, device, or channel) containing the resource may be in the 
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same file as the code defining the requesting process or another file. The other- 
file could contain code or be a resource-only file. A process may not need 
explicitly to unload a resource it no longer needs. 

With the low cost of disk storage, it may be desirable in some instances for the 
5 same installation of an operating system to provide, transparently to the user, 

appropriate resources for a number of languages. This would allow users of 
various tongues to share the same computer. The user would log on, select a 
desired language, and use the computer, thereafter seeing all resource-based 
operating system features in the chosen language. However, for an operating 
1 0 system built around the above resource management regimes, the options 

available to modify the operating system to accommodate selectable languages 
appear quite problematic, as discussed below. 

To provide multilingual support, one option might be to provide a different set 
of binary files for each language. Considering there might be on the order of a 

1 5 thousand bmary files containing language-specific resources in an complex 

operating system and that it might be desired to support many different 
languages, the number of binary files to be installed would be large indeed. In 
addition to the labor required to provide for the selection of a language by the 
user, the redundancy in the resulting mass of files would be tremendous 

2 0 because all language-non-specific resources would be duplicated for each 

language supported. Not only would the language-non-specific resource 
require duplication, but also all the code sections; 

Another option might be to install the operating system binary files anew, each 
time a new user requiring a different language logged on. This option is 

2 5 unattractive because it would take a great deal of time. 

Still anotiier option might be to provide the different language-specific 
resources in each binary file. This would eliminate tiie redundancy of the first 
option smce each binary file would only add language-specific resources. 
However, this option would require receding of each binary file, so it also is 

30 not an elegant option. Something similar to this is currently done on a very 

limited basis. Some binary files contain alternate resources, each being 
preferred depending on tiie language or countiy of the user. The code sections 



of these binary files define processes that address a different resource based on 
a "guess" as to the preferred language of resource. This guess is made based on 
the settings of some system parameter, for example, which date format has 
been selected. So, for example, if a Russian'style of date is selected, the 
resources tagged as Russian might be loaded. 

There is at least one type of operating system that now provides for language 
selection on a limited basis. This operating system provides separate text files 
for each language. When a process requires a text file resource in a particular 
language, the operating system addresses the appropriate file. The user can 
select his default language of choice through a system variable. 
As mentioned briefly, at least one current operating system (Windows®) 
provides some support for the creation of language-specific libraries, for 
example text messages. A system variable is defined indicating the locale 
(Note, the locale of a system is not a language setting. Locale is a mixture of 
language and location) of the operating system installation and this variable 
can be used by the applications running on the operating system to foraiat 
messages specifically for the current language. This requires, however, that the 
process (the application) identify precisely the appropriate language resource 
and where it is located. As a model for conversion it would entail extensive 
recoding. 

None of the prior art operating system regimes offers a model suggesting how 
to provide multilingual support by the operating system in a very automatic 
way. Also, none suggests means of preserving some of the inherent economies 
of binary files with code and re^urce sections in the same file. The simple 
transfomiations suggested above to provide the desired functionality appear to 
be unduly expensive and/or bulky in terms of the redundant data required. Any 
conversion that is readily implemented would likely have to be a system that 
departs significantly &6m any of the prior airt systemk. 
Referring to Fig. 1, in a common operation in a prior art operating system, a 
bmary file 20 is loaded. The binary file 20 contains a code section 10 and a 
resource section 30 and may be any file unit of the operating system or one 
supplied by a third party. For example, the binary file 20 could be an 
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executable binmy, a dynamic link library (DLL), or a device driver. The 
resource section 30 may contain some of the resources used by the code 
section, particularly those resources peculiar to the requirements of the 
processes generated by the code section 10 and ?which may be.pnloaded from 
memory when the processes defined in the code section 10 are no longer 
required. In other words, the resources 30 are those that may be required by 
processes encoded in the code section 10 and once those processes are 
terminated, there is no longer any need to maintain the resources contained in 
resource section 30 in memory. For example, the binary file 10 could be a core 
resource or an application that is supplied with the operating system such as a 
stripped-down text editor. For the editor, for example, when the user 
terminates the editor program, the resources required by this text editor would 
no longer be required. The binary file 20. including code 1 0 and resources 30, 
would be removed from memory. Of course, the code section 10 could use 
other resources from other files and may also use other processes as weU. 
Referring to Fig. 2, resources 85 and the code 55 that uses it may also be 
located in separate respective files 25 and 22.. For example, the resource 85 
addressed by an application 55 defined in a piece of code 50 may be contained 
in a resource-only DLL or a separate file 25 that contains code 70 and 
resources 60. The application 55 may reside in a file that also contains 
resources 40. Another operating system device may be used to find the file by 
resource type and name. The management (loading and unloading) of the 
resources maybe handled by the resource loader. 

Referring to Fig. 3,.resources are addressed by a process 1 10 using a resource 
loader 130 and a resource finder 135. The resource loader is an operating 
system facility that provides access to a resource datum 125 given a resource 
module handle and resource handle. The resource module handle, which 
indicates where the resource datum, specified by the resource name, can be 
found, is created by the resource finder. The resource name, type, and a 
language (the latter is optional) are provided to the resource finder 135 which 
returns a resource module handle. If fce resource is in a module other than the 
one that generated the caUing process, the handle of that module must be 
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provided to the resource finder as well. The resource type may specify for 
example a bitmap, an animated cursor, a font resource, a menu resource, a 
string-table entry, etc. 

The resource loader loads the specified resource into memory. It requires a 
resource module handle and resource handle. The resource module handle is 
the module whose executable file contains the resource. The resource handle 
identifies the resource to be loaded. The resource loader 130 returns a handle 
to the memory block containing the data associated with the resource. The 
description shown in Fig. 3 is consistent with either of the situations shown in 
Fig. 1 or Fig. 2. Note that examples of the above functions are defined in 
documentation relating to the Windows® APIs FindResource and 
LoadResource. Note also that the resource may be loaded in a prior operation 
as well as part of a call for a resource as described above. For example in the 
Windows® operating system, a call to LoadLibrary could result in the loading 
of a module into memory. 

Referring to Fig. 4» a generalized schematic of how resources may be 
addressed in an operating system is shown. A resource handler 230 is used by 
a process 210 to obtain access to a resource datum 220, The resource handler 
230 may consist of several different devices provided by the operating system, 
for example as discussed with reference to Fig, 3, The process identifies the 
requested resource to the handler 230 and may tell the handler where the 
resource can be found, such as a file name, identifier of a module 250 or some 
other information. The resource handler 230 may need to load the resource 
220, possibly included in a module 250, into memory or some other means for 
making the data accessible 240 providing access to the process 210. The 
process 210 is given a handle, address, pointer, etc. to access the resource 220. 
The hnportant features of the process described by Fig. 4 are that tiie process 
identifies the resource required and the operating system provides the process 
with access to fiiat resource. The resource may reside on a disk, on another 
computer connected by a network, provided through a communications port or 
any other mechanism for transferring data to a process on a compute. The 
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operating system may, as part of the request, transfer the resource to a different 
medium, say, for example, from disk to memory, before access to the resource 
by the process is possible. 

Siimniary f >f tViB TnvRntion 

An operating system scheme provides resource-handling components 
that provide features for handling multiple-language resources without 
requiring any specific directions from the processes requestmg the resources. 
This allows the operating system to provide multilingual support while using 
existing resource and executable binary files without modification of these 
elements. That is, a user is enabled to select a language for the user interface 
and the resource loader will automaticaUy redirect calls for resources to the 

appropriate resources. 

Note that throughout the following description, the notion of loading 
data into memory is not intended to be construed literally as actuaUy taking 
data from a file and putting it into memory. In the operating system context 
contemplated by the invention, the actual loading of data into physical 
memory is performed by low level operating system fimctions. Each process 
may have a virtual memoiy space that does not coincide with actual physical 
memory. When, in the following discussion, the step of loading and unloading 
data fmm memory is spoken of, it is intended to be interpreted broadly as any 
operating system fimction that makes data accessible to the process. 
From the standpoint of the processes requesting resources, the interactions 
with operating system.devices are the same as for handUng resources of a 
single language. The operating system resource-handling components for 
finding resources and returning them to a requesting process are modified to 
dynamically generate a path to an altamate-language resource module. The 
generation of the path may be in response to a resource identifia: and an 
optional module handle provided by the process requesting the resource and 
also in response to a systan-wide opwating us»-setting specifying a chosen 
language for the user-interfece. The path to the alternate-language resource is 
used instead of the module handle, if any, supplied by the process. 
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By generating the module handle dynamically, the operating system may be 
expanded without modifications to any perraanait facility to correlate base 
module bandies (the ones used by the callmg process) and the alternate- 
language resource modules. Since the look-up table is generated, dynamically, 
5 it is automatically created for the purpose of savmg steps and is never out of 

date. When new modules are added to the operating system, alternate language 
modules can be added and the algorithm used to generate alternate module 
handles without any central data housekeeping. As long as there is no collision 
between a new module name and an existing module name, the module and 
10 any code using it, or any binary file containing code and resources, may be 

added to the operatmg system without making any centralized changes. 
The system automatically loads and frees alternate-language modules as 
necessary, and transparently to the user and the processes requesting resources. 
Alternate language resources reside in modules (dynamic link libraries or 
1 5 DLLs, as defined in Windows® parlance, in a preferred implementation), each 

uniquely specified by a path and module name as: 
<modulej)ath>\mui\<language_ID>\<module__nam6> 
In other words, the operating system loads an alternate-language resource module 
from a language-specific subdirectory of the original module's load path. The path and 
2 0 module name ai€ dynamically generated using the same name as the original module 
name supplied by the calling process. The element <laiiguage_ID> may be some 
compact code representing the language. For example, it could be based on ISO 639 
language standard abbreviation plus, possibly, a sublanguage designator or a Win32 
language id including primary and secondary components. 

2 5 Alternate languages may be requested with varying degi^ of specificity. 

That is, one may request (French) French, Swiss French, or Canadian French 
at one level of specificity or just French at a lower level of specificity. For the 
process of generating an alternate language resource module handle to be 
robust, the algorithm may involve multiple stq>s to enable it to reconcile a 

3 0 system-level request for a user-interface language with one degree of 

specificity and an availability of alternate language resources provided with 
another degree of specificity. Suppose, for exainple, the user requ^ts Swiss 
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French upon logging into the operating system. This specifies a user-variable 
that mandates that for all process able to comply, that Swiss French resources 
should be used. The resource loader (or library loader) algorithm that 
generates alternate-language resources should be able to deal with situations 
where only an approximation to the requested language is available. Suppose 
in the above example, that only French and various other primary alternate 
languages are available and not specifically Swiss French. It is desirable for 
the algorithm to load the French alternate language resource upon a request 
rather than to make some other default choice that is not as close to the 
system-level mandate indicated in the system user language ED. Thus, multiple 
levels of approximation may be defined for the algorithm, for example, as 
follows. 

First, the algorithm may deteraune if, in the module path specified by 
•<module _palh>V' there exists a subdirectory with an identifier equivalent to 
the current user language ID, that is, with the name "\mui\<language_ID>\". If 
this first test fails, the algorithm may detemaine if there exists a subdirectory 
of "<inodule_path>\'' with an identifier equivalent to the primary language ID 
corresponding to the current user language ID, that is, with the name 
"\mui\<primaiyJanguage_ID>V'. If no system user language ID is specified, 
the algorithm may be able to use a surrogate to resolve a subdirectory, for 
example, some preference that suggests the locality of the user such as a 
preference as to date or monetary format conventions. Alternatively, a 
language-neutral alternate resource module may be invoked. Other steps, 
which may be placed in any desired priority, could be the selection of a default 
alternate language resource subdirectory, a substitute language where the one 
specified by the user language ID is not available but a fair substitute language 
spoken in the likely locale is. For example, if Canadian French is requested in 
the user language ID, and neither Canadian French nor French are available, 
but Canadian English is available, then the latter could be used. The above 
process of identifying preferred alternate resources according to a priority 
system allows the specificity of alternate language resources to be increased. If 
the operating system ships with only primary languages (e.g., English, but no 



- 10 - 



British English, Canadian English, etc.) the user may add more specific 
languages later and the user's choice implemented transparently and 
automatically. 

To speed processing, the mapping obtained by generating each alternate 
module path dynamically is preserved in a look-up table. When a calling 
process calls the same resource, the alternate resource module may be obtained 
from the look-up table instead of generatbg the path and handle dynamically. 
Note that by preserving the result of the dynamic generation of an alternate 
resource module ID, the steps of the robust algorithm discussed above do not 
have to be repeated each time a request for a resource is made. 
In addition, a clean-up table is generated to help the modified resource loader 
load and free memory as system requirements permit. The clean up table lists 
the loaded alternate resource modules and the processes that requested them. 
When, for example, the process requesting a resource is temiinated, the 
resource module requested by the t^minated process may be unloaded from 
memoiy. 

Note that the operating system keeps track of resources that are loaded and 
unloaded by generating entries in a loader data table. The loader data table 
indicates the processes that required the loading of resource modules so that 
these modules can be unloaded when the process tenninates or as other system 
requirements indicate. For modules that are loaded by the applications directly 
using, for example in Windows NT, the LoadLibraryEx fimction, the module's 
identity may not be "known" to the resource loader described above. That is, 
no loader data table entry is generated. In this, case, the facility that loads the 
resource module (e.g., LoadLibrary) may inquire as to the existence of an 
alternate-language resource and load it instead of the module requested by the 
application. If the application or process does use an operating system facility 
that does generate a loader data table oitry, then die module would not have to 
be loaded until a request is made for a resource from fhe resource loader by the 
application or other process. 

According to an embodiment, the invention is a method performed by an 
operating system. The method redirects a call by a calling process for a first 
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datum residing in a first binary file. The following steps are performed: storing 
in an operating user-setting independently of the calling process, a language 
identifier; when a second binary file corresponding to the language identifier 
and also to an identifier of either the first datum or the first binary file exists: 
5 (1 ) dynamically generating a path to the second binary file responsively to the 

language identifier and the either the first datum or the fn-st binary file; (2) 
storing the path in a look-up table correlating a process module identifier 
identifying the first binary file and an alternate module identifier identifying 
the second binary file; and (3) making an alternate datum in the second binary 

X 0 file accessible to the calling process instead of the first datum. 

According to another embodiment, the invention is also a method performed 
by an operating system. The method redirects a call by a calling process for a 
first resource datum residing in a first binary file containing both executable 
code defining the calling process and resource data. The calling process is 

15 defined in the code. The method has the following steps: storing in a variable, 

independently of the calling process, a language identifier; when a second 
binary file corresponding to the language identifiw and also to either the first 
resource datum or the first binary file exists: (1) dynamically generating a path 
to the second binary file responsively to the language identifier and the either 

2 0 the first resource datum or the first binary file; (2) making an alternate 

resource datum in the second bmaiy file accessible to the calling process 
instead of the first resource datum. 

According to still another embodiment, the invention is a method of adding 
' • multilingual capability to an operating system having functions to address first 

2 5 resource data in executable bmary files. The method includes the following 

- steps: adding a selectable user-setting for storing a selected language 
identifier; adding at least one alternate language resource file containing 
resource data each corresponding to a respective one of the first resource data; 
and modifying a resource loader to redirect calls for each of the fu^ resource 

3 0 data to a respective one of the alternate language resource data responsively to 

a selected language stored in the selected language identifier. 



wo OD/1 0078 PCTAJS99/1 8347 

- 12 - 

According to an embodiment, the invention is a method performed by an 
operating system. The method addresses data responsively to a call by a 
calling process for a first datum, The method has the following steps: 
determining an existence of an altemate.language file corresponding to the 
5 first datum; returning at least one datum from the alternate language file to the 

calling process when a result of the step of determining is an indication that 
the alternate language file exists; returning the first datum to the calling 
process when a result of the step of determining is an indication that the 
alternate language file does not exist. 

10 According to an embodiment, the invention is a method performed by an 

operating system. The method redirects a call by a calling process for a first 
datum residing in a first binary file. The following steps are performed: storing 
in an operating system variable mdependently of the calling process for each 
user, a language identifier responsively to a detection of a second binary file 

1 5 corresponding to fiie language identifier and also to an identifier of either the 

first datum or the first binary file: (1) dynamically generating a path to the 
second binary file responsively to the language identifier and the either the 
first datum or the first binary file; (2) storing the path in a look-up table 
correlating a process module identifier identifying the first binary file and an 

2 0 alternate module identifier identifying the second binary file; and (3) making 

an alternate datum in the second binary file accessible to the calling process 
instead of the first datum. 

Rnef Description of the Drawings 

Fig. 1 is a schematic drawing of a binary file containing a code section 

2 5 that defines a process that calls for a resource in a resource section of the same 

binary file. 

Fig. 2 is a schematic drawing of two binary files, one of which contains 
code and may or may not contain resources, and the other of which contains 
resources and may or may not contain code, the code of the first file defining a 

3 0 process that calls resources in the second file. 
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Fig. 3 is a schematic illustration of a resource loader and resource 
finder being used by a process to retrieve a resource accordmg one 
embodiment of the prior art. 

Fig. 4 is a schematic illustration of a.resource handler in a generalized 
5 description of a process of retrieving resources by a process on a computer. 

Fig. 5, is a schematic illustration of a process of calling for a resource datum 
through an operating system in a modification of the prior art process shown in 
Fig. 3. 

0 Referring to Fig. 5, a process of calling for a resource datum through 

an operating system in a modification of the prior art process shown in Fig. 3, 
is shown. Processes within the resource loader 130 and resource finda- 135, 
described with reference to Fig. 3, are modified to produce a process as 
illustrated in Fig. 5. In overardiing terms, the process of Fig. 5 redh-ects a call 

.5 by the process for a particular resource to an alternate-language resource so 
that the process receives a resource associated with a selected user-interface 
language instead of the defiailt resource for the process. In an embodiment, 
loading of alternate resources only "kicks in" if the process did not specify the 
language it wants to load. In other words, a process tries to load resources and 

1 0 . doesn't really care about which language. In the prior-art system the resource 
loader would return the resources firom either the resource section of the 
module itself, or firom an external module, which the process specified to load 
resources from. In the present embodiment of a multilingual user interface 
system, the resource loader will load alternate resources if the process didn't 

2 5 specify a particular language or other particular classification for the resource. 

The process requests a memory handle Scorn the resource finder 320 just as in 
the prior art embodiment of Fig. 3. Howeva:. in this case, the handle is a 
handle reforing to an alternate language resource, if one is available. The 
resource finder tries to identify a resource indicated by a selected usar- 

3 0 inter&ce language ID 33S . 
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Selected user-interface language ID 335 is a user-setting. The selected user- 
interface language ID 335 could be established, for example, by a user logging 
in and selecting a language from a list of options. The selected user-interfece 
language ID 335 is then stored until changed. 
A process 310 requests a memory handle for a resource by sending to a 
resource finder 320 a resource name and type. If the resource were in a module 
other than the one defming the calling process 310, the resource module 
handle would also be sent to the resource finder 320. If the module handle is 
not sent, the resource finder already has access to the module handle from a 
loader data table because the module is the same as the one generating the 
process requesting the resource. (As discussed in the background section, 
resource finder and resource loader are often used to access resources in the 
same binary file as the code generating the requesting process) It is also 
possible for the process to request a resource that is language-specific and the 
process of satisfying such a request may be outside the steps relating to the 
invention and satisfied by prior art methods (See for example a description of 
LoadResource described in litfp*//www minm.<:ftft.cnm/m5dn/.^ In the latter 
case, a language ID may be passed to the resource finder. 
The operating system is modified to maintain a table of alternate resource 
module handles 323, which have been generated previously by calls to the 
resource finder 320. So if another process already requested a resource from 
the same module and the module is akeady con-elated to an alternate resource 
module, the alternate module handle can be quickly obtained from the 
alternate resource module table 323. If^ere is no entry for the resource, the 
operating system generates an alternate module path dynamically. 
To dynamically generate an alternate module path, an algorithm 325 is 
employed. The algorithm 325 may be based on some assumed organization of 
resource files, which indicate whether an alternate language resource file exists 
for the ^ecified resource. In the present embodiment, the alternate language 
resource files are located in subdirectories of the requested module's path, each 
distinguished by a filaiame correlated uniquely to a language identifier. 
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Within each language's subdirectoiy are stored the alternate language resource 
files, each named after the original module. 
<module_path>\mui\<language_ID>\<lnodule_name> 
In other words, the operating system loads an altemate-langpage resource 
5 module from a language-specific subdirectory of the original module's load 

path. If the original module, for a system that was not multilingual enabled, 
was "<path l>\<filename 1>," the path for the alternate language module 
would be "<path l>\mui\<language ID l>\<filename 1>" assuming the 
Unguage indicated by selected user-interface language ID 335 is "language ID 
10 1." 

The organization of the alternate language resources can be done in various 
alternative ways. Breaking them down into language-specific modules, each 
corresponding to the regular module (the one ordinarily requested in a single- 
language operating system) avoids any need for additional memory as would 
15 occur if for each resource module, the fesourcte of the various languages were 

combined into a single module. 

Given the path structure used to store modules, it is straightforward to 
construct a path for an alternate language module corresponding to any 
language indicated by the selected user-interface language ID 335 and the 
20 original called-for path and module name. This path is used by the resource 

finder 320 to provide a resource handle. The creation of the resource handle is 
done in the same way as in the prior art. The difference is that the resource 
handle in this instance directs tiie process to a resource datum 350, which was 
identified in a subdirectory of the original module path. In Fig. 5, the resource 

2 5 datum 350 was in an alternate resource module for "binary file 2" where the 

selected user interfece language ID was language ID 2. 
The path and module name are dynamically generated using the same name as 
the original module name supplied by the calling process. The element 
<anguage_ID> may be some compact code representing the language. For 

3 0 example, it could be based on ISO 639 language standard abbreviation plus, 

possibly, a sublanguage designator or a Win32 language id including primary 
and secondary components. 
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In a preferred embodiment of the invention, the algorithm is robust in that it 
does much more than simply construct a path assuming there exists an 
alternate-language resource for the requested data. Alternate languages may be 
requested with varying degrees of specificity. Also, it is possible that no 
alternate-language resource may be available or that an alternate resource is 
available, the resource being different jfrom the base resource in some respect 
other than language. The algorithm and associated processes are robust enough 
to deal with and exploit these situations as well as the straightforward scenario 
depicted in Fig. 5. 

The selected user interface language may be very specific. For example, a user 
may request French, Swiss, or Canadian French. The algorithm may involve 
multiple steps to enable it to reconcile a system-level request for a user- 
interface language with one degree of specificity and an availability of 
alternate language resources provided with another degree of specificity. If the 
user requests French French upon logging into the operating system, only an 
approximation to the requested language may available. To deal with such 
situations, the algorithm and associated processes may operate according to a 
built-in hierarchy of steps as follows. 

First, the algorithm inay determine if, in the module path specified by 
"<module_path>\mui\" there exists a subdirectory with an identifier equivalent 
to the current user language ID, that is, with the name "\<language_ID>V*. If 
this first test fails, the algorithm may determine if there exists a subdirectory 
of "<module_path>\mui\" with an identifier equivalent to the primary 
language ID corresponding to the current user language ID, that is, with the 
name 'VprimaryJanguage_ID>\". If no system user language ID is specified, 
the algorithm may be able to use a surrogate to resolve a subdirectory, for 
example, some preference that suggests the locality of the user such as a 
preference as to date or monetary format conventions. Alternatively, a 
language-neutral alternate resource module may be invoked. Other stq>$, 
which may be placed in any desired priority, could be the selection of a de&ult 
alternate language resource subdirectory, a substitute language where the one 
specified by the user language ID is not available but a predefined substitute 
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language is often spoken in the likely locale is, for example, if Canadian 
French is requested in the user language ID, and English is available. The 
above process of identifying preferred alternate resources according to a 
priority system allows the specificity of alternate language resources to.be 
increased. If the operating system ships with only primary languages (e.g., 
EngUsh, but no British English, Canadian EngUsh, etc.) the user may add more 
specific languages later and the user's choice implemented transparently and 
automatically. 

Note that the above fimctionality does not interfere with the normal requests 
for a resource for a specific language, such as made with the FindResourceEx 
function in Windows®. If a specified language ID is provided by the 
requesting process, the alternate-language resource scheme above would not 
reroute the request to another resource module. 
AftCT the algorithm 325 that forms the pafli has settled on a resource path, 
version checks and any oflier integrity checks can be performed on tiie 
identified file before making it accessible to the requesting process. If, as a 
result of the processes described with referaice to Fig. 5, the alternate- 
language module 370 was newly placed in memory or otherwise made 
accessible by the call to resource finder 320, anew entry may be placed in the 
alternate resource module table 323. Finally a handle may be returned to the 
calling process to allow the process to access the requested resource. The lattrar 
may involve a step to another function, the resource loader 330, to load the 
data into memory and provide a handle for the process to use to access the 
data. 

Note that where Fig. 5 and the attendant discussion indicate that the module is 
loaded into memoiy, this may not need to be done explicitly by the resource 
finder or even the lesouroe loader. The only requiremoit is the appropriate 
data is made available to the process. The opwating system may handle the 
actual movement of data through its I/O and memory managonent facilities. 
The import of what is described above with refisrence to Fig. 5 is that a request 
by a process for a resource, whose guts are diffisrent for different languages, is 
automatically redirected transparently to the requesting process. The code 
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defining the process does not need to be modified for the operating system to 
be multilingual enabled. Fig. 5 and the attendant discussion describe the 
process of redirecting requests for data iii the context of resources that are 
incorporated in binary files that also contain executable code. The same basic 
5 formula can be expanded to embrace the access of data in resource-only files, 

for example, DLLs. 

Note that in the above discussion, where a process calls for data to be 
loaded into memory or unloaded from memory, such a step should be viewed 
in the broader sense of being mapped into the address space of a process. This 

10 is because the operating system facilities for mapped I/O blur the concrete 

notions connected with loading data from disk into memory. In other words, 
current operating systems make it possible to allow a process to access data on 
a disk following steps without necesisarily being involved in the explicit steps 
of loading data into memory, since this concrete step can be handled 

15 transparently by the operating system's I/O system and virtual memoiy 

management fimctions. 

The above process may map the alternate resource module as a simple 
data file mto the address space of the calling process. The details underlying 
this process are known in the prior art, for example in Windows®, this is done 

20 by code defining an operating system function called LoadLibrary. 
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CT,ATMS 

What is claimed is: 

1. In an operating system, a method for redirecting a call by a calling 
process for a first datum residing in a first binary file, said method comprising 
the steps of: 

storing in a variable independently of said calling process, a language 
identifier, 

when a second binary file, corresponding to said language identifier 
and also to an identifier of dther said first datum or said first binary file, is 
found: 

dyiamically generating a path to said second binary file responsively 
to said language identifier and said either said first datum or said first 
binary file; 

storing said path in a look-up table conelating a process module 
identifier identifying said first bmaiy file and an alternate module 
identifier identifying said second binary file; and 
making an alternate datum in said second binary file accessible to said 
calling process instead of said first datum. 

2. A method as in claim 1, wherein said step of making includes mapping said 
alternate datum into an address space of said calling process. 

3. A method as in claim 2, wherein said calling process is defined in a code 
portion of said first binary file. 

4. A method as in claim 2, wherein said step of dynamically generating 
includes generating a path that includes a language-specific subdirectory. 

5. A method as in claim 2, wherein said st^ of making includes generating a 
handle to said alternate datum for use by said calling process in accessing said 
alternate datum. 

6. A method as in claim 2, wherein said second binary file includes both code 
and resource data, said alternate datum bdng at least a portion of said resource 
data. 
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7. A method as in claim 2, further comprising the step of, when a second 
binary file corresponding to said language identifier and also to either said first 
datura or said first binary file is not found, making sdd first datum accessible 
to said calling process, 
5 8. A method as in claim 2, wherein said first datum is one of data defming an 

icon, a cursor, a menu, a dialog box, a bitmap, an enhanced metafile, a font, an 
accelerator table, a message-table entry, a string-table entry, or a version. 
9. A method as in claim 1, wherein said step of dynamically generating 
includes generating a path that includes a language-specific subdirectory. 
10 10. A method as in claim 9, wherein said step of making includes generating a 

handle to said alternate datum for use by said calling process in accessing said 
alternate datum. 

1 1 . A method as in claim 9, wherein said second binary file includes both code 
and resource d? t a, said alternate datum being at least a portion of said resource 

15 data. 

12. A method as m claim 9, further comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first datum or said first binary file is not found, making said first datum 
accessible to said calling process. 

20 1 3. A method as in claim 9, wherdn said first datum is one of data defining an 

icon, a cursor, a menu, a dialog box, a bitmap, an enhanced metafile, a font, an 
accelerator table, a message-table entry, a string-table entry, or a version. 

14, A method as in claim 1, wherein said step of making includes generating a 
handle to said alternate datum for use by said calling process in accessing said 

25 alternate datum. 

15, A method as in claim 14, wherein said second binary file includes both 
code and resource data, said alternate datum being at least a portion of said 
resource data. 

16, A method as in claim 14, fiirflier comprising the step of, when a second 
3 0 binary file that corresponds to said language identifier and also to either said 

first datum or said first binary file is not found, making said first datum 
accessible to said calling process. 
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1 7. A method as in claim 14, wherein said first datum is one of data defining • 
an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced metafile, a font, 
an accelerator table, a message-table entry, a string-table entry, or a version. 

1 8. A method as in claim 1. wherein said second binary file includes both code 
and resource data, said alternate datum being at least a portion of said resource 
data. 

19. A method as in claim 1 8, further comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first datum or said first binary file is not found, making said first datum 
accessible to said calling process. 

20. A melJiod as in claim 18, wherein said first datum is one of data defining 
an icon, a cursor, a menu, a dialog box, a bitm^. an enhanced metafile, a font, 
an accelerator table, a message-table entry, a string-table entry, or a version. 

2 1 . A method as in claim 1 , fiirther comprising the step of, when a second 
binary file that does not correspond to said language identifier and also to 
either said first datum or said first binary file, making said first datum 
accessible to said calling process. 

22. A ihethod as in claim 21, wherem said first datum is one of data defining 
an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced metafile, a font, 
an accelerator table, a message-table entry, a string-table entry, or a version. 

23. A method as in claim 1 , wherdn said first datum is one of data defining an 
icon, a cursor, a menu, a dialog box, a bitmap, an enhanced metafile, a font, an 
accelerator table, a message-table entry, a string-table entry, or a version. 

24. A method as in claim 1 . wherein said first datum is a resource datum. 

25. A method as m claim 1, wherein said calHng process is defined in a code 
portion of said first binary file. 

26. In an operating system, a method for redirecting a call by a calling 
process for a first resource datum residing in a first binary file containing both 
executable code defining said calling process and resource data, said calling 
process being defined in said code, said method comprising the steps of: 

storing in a variable independently of said calling process, a language 
identifier. 
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when a second binary file, corresponding to said language identifier 
and also to either said first resource datum or said first binary file, is found: 
dynamically generating a path to said second binary file responsively 
to said language identifier and said either said first resource datum or 
said first binary file; 

making an alternate resource datum in said second binary file 
accessible to said calling process instead of said first resource datum. 

27. A method as in claim 26, wherein said step of making includes mapping 
said altemate resource datum into an address space of said calling process. 

28. A method as in claim 27, wherein said step of dynamically generating 
includes generating a path that includes a language-specific subdirectory. 

29. A method as in claim 27, wherein said step of making includes generating 
a handle to said altemate resource datum for use by said calling process in 
accessing said altemate resource datum. 

30. A method as in claim 27, wherein said second bmaiy file includes both 
code and resource data. 

3 1. A method as in claim 27, fiirther comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first resource datum or said first binary file is not found, making said first 
resource datum accessible to said calling process. 

32. A method as in claim 27, wherein said first resource datum is one of data 
defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 
metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version. 

33. A method as in claim 26, wherein said step of dynamically generating 
includes generating a path that includes a language-specific subdirectory, 

34. A method as in claim 33, wherein said step of making includes generating 
a handle to said altemate resource datum for use by said calling process in 
accessing said alternate resource datum. 

35. A method as in claim 33, wherein said second binary file includes both 
code and resource data. 
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36. A method as in claim 33, further comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first resource datum or said first binary file is not found, making said first 
resource datum accessible to said calling process. 

37. A method as in claim 33, wherein said first resource datum is one of data 
defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 
metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version. 

38. A method as in claim 26, wherein said step of making includes generating 
a handle to said alternate resource datum for use by said calling process in 
accessing said alternate resource datum. 

39. A method as in claim 38, wherein said second binary file includes both 
code and resource data. 

40. A method as in claim 38, further comprising the stq> of, when a second 
binary file that corresponds to said language identifier and also to either said 
first resource datum or said first binary file is not found, making said first 
resource datum accessible to said calling process. 

41. A method as in claim 38, wherein said first resource datum is one of data 
defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 
metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version. 

42. A method as in claim 26, wherein said second binary file includes both 
code and resource data. 

43. A method as iii claim 42, fiirther comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first resource datum or said first binary file is not found, makmg said first 
resource datum accessible to said calling process. 

44.. A method as in claim 42, wherein said first resource datum is one of data 
defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 
metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version. 
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45. A method as in clam 26, further comprising the step of, when a second 
binary file that corresponds to said language identifier and also to either said 
first resource datum or said first binary file is not found, making said first 
resource datum accessible to said calling process. 
5 46. A method as in claim 45, wherein said first resource datum is one of data 

defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 
metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version, 

47. A method as in claim 26, wherein said first resource datum is one of data 
10 defining an icon, a cursor, a menu, a dialog box, a bitmap, an enhanced 

metafile, a font, an accelerator table, a message-table entry, a string-table 
entry, or a version. 

48. A method of adding multilingual capability to an operating system having 
fimctions to address first resource data in executable binary files, the method 

1 5 comprising the steps of: 

adding a selectable usCT-setting for storing a selected language identifier; 
adding at least one alternate language resource file containing resource data 
each corresponding to a respective one of said first resource data; and 
modifying a resource loader to redirect calls for each of said first resource data 

20 to a respective one of said alternate language resource data responsively to a 

selected language stored in said selected language identifier* 

49. In an operating system, a method of addressing data responsively to a call 
by a calling process for a first datum, comprising the steps of: 
determining to existence of an alternate language file corresponding to said 

25 first datum; 

returning at least one datum firom said alternate language file to said calling 
process when a result of said step of determining is an indication that said 
alternate language file exists; 

returning said first datum to said calling process wheri a result of said step of 
3 0 determining is an indication that said alternate language file does not exist 
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50. In an operating system, a method for redirecting a call by a calling 
process for a first datum residing in a first binary file, said method comprising 
the steps of: 

storing in a variable independently of said calling process, a language 
identifier; 

responsively to a detection of a second binary file, corresponding to 
said language identifier and also to an identifier of either said first datum or 
said first binary file: 

dynamically generating a path to said second binary file responsively 

to said language identifier and said either said first datum or said first 

binary file; 

storing said path in a look-up table correlating a process module 
identifier identifying said first binary file and an alternate module 
identifier identifying said second binary file; and 

making an alternate datum in said second binary file accessible to said calling 

process instead of said first datum. 
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